Implement invoice fields feature #73887
Conversation
|
Hey, I noticed you changed If you want to automatically generate translations for other locales, an Expensify employee will have to:
Alternatively, if you are an external contributor, you can run the translation script locally with your own OpenAI API key. To learn more, try running: npx ts-node ./scripts/generateTranslations.ts --helpTypically, you'd want to translate only what you changed by running |
Codecov Report✅ Changes either increased or maintained existing code coverage, great job!
|
ShridharGoel
changed the title
melvin-bot
bot
requested review from
joekaufmanexpensify and
rojiphil
and removed request for
a team
ShridharGoel
changed the title
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| }; | ||
|
|
||
| API.write(WRITE_COMMANDS.DELETE_POLICY_REPORT_FIELD, parameters, onyxData); | ||
| const fieldsToDelete = reportFieldsToUpdate.map((reportFieldKey) => allReportFields[reportFieldKey]).filter((reportField): reportField is PolicyReportField => !!reportField); |
There was a problem hiding this comment.
❌ PERF-13 (docs)
The .map() and .filter() chain creates an intermediate fieldsToDelete array only to check the target property. This creates unnecessary overhead by mapping all fields before checking a simple property.
Suggested fix: Check the target property directly on allReportFields without creating the intermediate array:
const isInvoiceField = reportFieldsToUpdate.length > 0 && reportFieldsToUpdate.every((reportFieldKey) => {
const reportField = allReportFields[reportFieldKey];
return reportField?.target === CONST.REPORT_FIELD_TARGETS.INVOICE;
});Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
| @@ -0,0 +1,222 @@ | |||
| import {FlashList} from '@shopify/flash-list'; | |||
There was a problem hiding this comment.
❌ CONSISTENCY-3 (docs)
This entire 220+ line component duplicates logic that should be shared with the report fields functionality in WorkspaceReportsPage.tsx. The two components have nearly identical structure, state management, rendering logic, and modal handling, differing only in:
- Routes used (
WORKSPACE_INVOICE_FIELDS_*vsWORKSPACE_REPORT_FIELDS_*) - Translation keys (
workspace.invoiceFields.*vsworkspace.reportFields.*) - Filter condition (
field.target === INVOICEvs\!value.target || value.target === EXPENSE) - Feature flags (
areInvoiceFieldsEnabledvsareReportFieldsEnabled)
Suggested fix: Extract the shared logic into a reusable component that accepts configuration props:
type FieldsSectionProps = {
policyID: string;
targetType: ValueOf<typeof CONST.REPORT_FIELD_TARGETS>;
featureFlagKey: keyof Pick<Policy, 'areInvoiceFieldsEnabled' | 'areReportFieldsEnabled'>;
routes: {
create: string;
settings: (id: string, fieldID: string) => string;
};
translations: {
title: string;
subtitle: string;
// ...other translation keys
};
};
function WorkspaceFieldsSection({policyID, targetType, featureFlagKey, routes, translations}: FieldsSectionProps) {
// Shared implementation
}Then use it from both invoice and report pages with different configurations.
Please rate this suggestion with 👍 or 👎 to help us improve! Reactions are used to monitor reviewer efficiency.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6e2ce0f070
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (!reportField || (expectedTarget && reportField.target !== expectedTarget)) { | ||
| return <NotFoundPage />; |
There was a problem hiding this comment.
The expectedTarget guard treats any report field without a target as invalid. Existing expense report fields created before this change typically have target unset, so opening their settings page will now render NotFound and block edits/deletes. This regression affects older policies until those fields are re-created. Consider treating a missing target as expense (or only enforce the check for invoice targets).
Useful? React with 👍 / 👎.
1 participant
Explanation of Change
Implement invoice fields feature.
Fixed Issues
$ #72584
PROPOSAL: #72584 (comment)
Tests
Offline tests
QA Steps
Same.
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectioncanBeMissingparam foruseOnyxtoggleReportand notonIconClick)src/languages/*files and using the translation methodSTYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))npm run compress-svg)Avataris modified, I verified thatAvataris working as expected in all cases)Designlabel and/or tagged@Expensify/designso the design team can review the changes.ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Android: Native
Screen.Recording.2026-02-02.at.1.01.56.AM.mov
Android: mWeb Chrome
Screen.Recording.2026-02-02.at.1.00.25.AM.mov
iOS: Native
Screen.Recording.2026-02-02.at.12.55.40.AM.mov
iOS: mWeb Safari
Screen.Recording.2026-02-02.at.12.58.09.AM.mov
MacOS: Chrome / Safari
Screen.Recording.2026-02-02.at.12.09.10.AM.mov
Screen.Recording.2026-02-02.at.12.12.09.AM.mov